Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / terms / kermit / b / ckuins.doc < prev next >

Wrap

Text File | 1993-08-09 | 63.1 KB | 1,345 lines

C-KERMIT 5A INSTALLATION INSTRUCTIONS FOR UNIX -*-text-*- 5A(189) Mon Aug 9 17:43:06 1993 F. da Cruz, Columbia University Copyright (C) 1985, 1992, Trustees of Columbia University in the City of New York. Permission is granted to any individual or institution to use this software as long as it is not sold for profit. This copyright notice must be retained. This software may not be included in commercial products without written permission of Columbia University. DISCLAIMER: The C-Kermit software is provided in source code form by Kermit Development and Distribution, Columbia University. The software is provided "as is;" no other warranty is provided, express or implied, including without limitations, any implied warranty of merchantability or implied warranty of fitness for a particular purpose. Neither Columbia University nor any of the contributors to the C-Kermit development effort, including, but not limited to, AT&T, Digital Equipment Corporation, Data General Corporation, or International Business Machines Corporation, warrant C-Kermit software or documentation in any way. In addition, neither the authors of any Kermit programs, publications or documentation, nor Columbia University nor any contributing institutions or individuals acknowledge any liability resulting from program or documentation errors. DOCUMENTATION C-Kermit 5A is documented in the book "Using C-Kermit" by Frank da Cruz and Christine M. Gianone, Digital Press, Burlington, MA, USA. Digital Press ISBN: 1-55558-108-0; Prentice-Hall ISBN: 0-13-037490-3. Price: US $34.95. In USA, call DECdirect at 1-800-344-4825, refer to order number EY-J896E-DP. OVERVIEW This file contains UNIX-specific information. For a description of general (system-independent) configuration options for C-Kermit, please read the file CKCCFG.DOC. For information about known limitations or bugs, and possible workarounds, see the files CKCKER.BWR and CKUKER.BWR. Once you have built C-Kermit according to the instructions in this file, you should install it in a directory that is in the users' PATH, but that is not likely to be overwritten when you install a new version of the operating system. A good candidate would be the /usr/local/bin/ directory. You should also install the man page, which is called ckuker.nr, in the man page directory for local commands, such as /usr/man/manl/, renamed appropriately, e.g. to kermit.l. It might also be a good idea to make a "Kermit library" directory for sample files and non-man-page-style documentation. /usr/local/lib/kermit/ might be a good place for this. Some of the files that could go there are: ckermit.ini The standard initialization file. Users should copy this to their home directories and rename it to .kermrc. There is no provision in UNIX C-Kermit for a system-wide intitialization file (but see below). ckermod.ini A sample customization file. Users should copy this file to their home directories, make any desired modifications (user- or site-specific customizations), and rename it to .mykermrc. ckermit.kdd A sample dialing directory file. ckermit.ksd A sample services directory. ckedemo.ini Macro definitions from "Using C-Kermit". ckevt.ini Command file to demonstrate special screen effects from "Using C-Kermit" ckcker.upd A file listing the updates, changes, and corrections made to C-Kermit since publication of "Using C-Kermit". ckcker.bwr The general C-Kermit beware file. ckuker.bwr The UNIX-specific C-Kermit beware file. Here is one method, suggested by Wayne Hauber and John Hascall of Iowa State University, of installing a single system-wide C-Kermit initialization file: "Rather than copy individual versions of .kermrc, we created a shell script that looks like: #!/bin/sh [ ! -f $HOME/.kermrc ] && { echo "Setting up kermit configuration file..." ln -s /usr/local/lib/.kermrc $HOME/.kermrc } exec /usr/local/bin/kermit.real $* We named this thing kermit and called the kermit executable kermit.real." BUILDING C-KERMIT FOR UNIX UNIX C-Kermit is built using the "make" utility, which contains the rules for building the program for each of the dozens of different kinds of UNIX systems that C-Kermit attempts to support. "make" is driven by a file called "makefile", which is normally distributed as ckuker.mak. You must rename this file to makefile before you can build the program: mv ckuker.mak makefile and then you type "make xxx", where xxx is the system you want to build C-Kermit for. These are listed in the comments at the top of the makefile. For example, to build C-Kermit for Berkeley UNIX 4.2, type: make bsd Also check to see if there are comments about your particular version in its makefile entry itself. Search for the make entry name followed by colon (e.g. "bsd:"). To add compilation options (which are explained later in this document) to your makefile entry without editing the makefile, include "KFLAGS=..." on the make command line, for example: make bsd KFLAGS=-DNODEBUG make bsd "KFLAGS=-DKANJI -DNODEBUG -DNOTLOG -DDYNAMIC -UTCPSOCKET" Quotes are necessary if the KFLAGS= clause includes spaces. The KFLAGS are added to the end of the CFLAGS that are defined in the selected makefile entry. For example, the "bsd" entry includes -DBSD4 -DTCPSOCKET, so the second example above compiles Kermit with the following options: -DBSD4 -DTCPSOCKET -DKANJI -DNODEBUG -DNOTLOG -DDYNAMIC -UTCPSOCKET (Notice how "-UTCPSOCKET" is used to negate the effect of the "-DTCPSOCKET" option that is included in the makefile entry.) WARNING: Be careful with KFLAGS. If you build C-Kermit, change a couple files, and then run make again using the same make entry but specifying different KFLAGS than last time, make won't detect it and you could easily wind up with inconsistent object modules, e.g. some of them built with a certain option, others not. When in doubt, "make clean" first to make sure all your object files are consistent. Similarly, if you change CFLAGS, LIBS, or any other items in the makefile, or you rebuild using a different makefile entry, "make clean" first. After you have built and tested the C-Kermit program successfully, you can discard the object (ck*.o) files, which are no longer needed. Use "make clean" to do this. If you don't need the source files (ck[cuw]*.[cwh]), you can remove them too. Then move the wermit program to the desired location and rename it to "kermit", for example: mv wermit /usr/local/bin/kermit chmod 775 /usr/local/bin/kermit This file gives some supplementary information, primarily intended for when none of the built-in makefile entries results in a satisfactorily working Kermit for your UNIX system. UNIX MAKEFILE The makefile is quite long, and at least two versions of UNIX, SCO Xenix/286 and 2.x BSD, cannot cope with its length. An attempt to "make sco286" gives the message "Make: Cannot alloc mem for env.. Stop". Solution: edit away some or all of the nonrelevant material from the makefile. (A separate version of the makefile is provided for BSD 2.x: ckubs2.mak.) Some make programs reportedly cannot handle continued lines (lines ending in backslash (\). If you have a problem with the makefile, try editing the makefile to join the continued lines (remove the backslashes and the following linefeed). Other makefile troubles may occur because tabs in the makefile have somehow been converted to spaces. Spaces and tabs are distinct in makefiles. If the makefile entry for your version of C-Kermit does not include -DDYNAMIC, try adding it. This should make the program image smaller, and it will allow you to use much longer packets and bigger window sizes. If this works on your system, please notify the author at the address above. If the makefile entry for your version of C-Kermit does not include TCP/IP support, but your UNIX system does support TCP/IP using the Berkeley sockets library, or some variation of it, try adding -DTCPSOCKET to your makefile entry. If it "almost works", there are some other switches you can add to force recognition of the various slightly-incompatible TCP/IP implementations (-DWOLLONGONG, -DEXCELAN, -DINTERLAN, etc). BUILDING C-KERMIT FOR UNIX FROM MS-DOS DISTRIBUTION DISKETTES If you have received C-Kermit on MS-DOS format diskettes (such as those distributed by Columbia), you should make sure that your DOS-to-UNIX conversion utility (such as "dosread") both: (1) changes line terminators in all files from carriage-return linefeed (CRLF) to just linefeed (LF) (such as "dosread -a") and remove any Ctrl-Z's, and (2) that all filenames are converted from uppercase to lowercase. If these conversions were not done, you can use the following shell script on your UNIX system to do them: ---(cut here)--- #!/bin/sh # # Shell script to convert C-Kermit DOS-format files into UNIX format. # Lowercases the filenames, strips out carriage returns and Ctrl-Z's. # x=$1 # the name of the source directory y=$2 # the name of the target directory if [ $# -lt 2 ]; then echo "usage: $0 source-directory target-directory" exit 1 fi if cd $1 ; then echo "Converting files from $1 to $2" else echo "$0: cannot cd to $1" exit 1 fi for i in *; do j=`echo $i | tr 'A-Z' 'a-z'` echo $x/$i =\> $y/$j tr -d '\015\032' < $i > $y/$j done ---(cut here)--- Cut out this shell script, save it as "convert.sh" (or any other name you prefer), then "chmod +x convert.sh". Then, create a new, empty directory to put the converted files in, and then "convert.sh /xxx /yyy" where /xxx is the name of the directory where the PC-format files are, and /yyy is the name of the new, empty directory. The converted files will appear in the new directory. CHECKING THE RESULTS Here are several quick checks you can run to tell whether your version of C-Kermit was built correctly for your UNIX system. 0. Start C-Kermit (usually by typing "./wermit" in the directory where you ran the makefile. Do you see the C-Kermit> prompt? If not, C-Kermit incorrectly deduced that it was running in the background. The test is in conbgt() in ckutio.c. If you can fix it for your system, please send in the fix (Hint: read about "PID_T" below). Otherwise, you can force C-Kermit to foreground mode by starting it with the -z command line option, as in "kermit -z", or giving the interactive command SET BACKGROUND OFF. 1. When you type characters at the C-Kermit prompt, do they echo immediately? If not, something is wrong with concb() and probably the other terminal mode settings routines in ckutio.c. Be sure you have used the most appropriate make entry. 2. At the C-Kermit> prompt, type "send *?". C-Kermit should list all the files in the current directory. If not, it was built for the wrong type of UNIX file system. Details below. In the meantime, try SET WILDCARD-EXPANSION SHELL as a workaround. 3. Create a file with a long name in your current directory, e.g.: % touch thisisafilewithaveryveryveryveryveryveryveryverylooooooooongname Check with ls to see if your version of UNIX truncated the name. Now start C-Kermit and type "send thisis<ESC>". Does Kermit complete the name, showing the same name as ls did? If not, wrong filesystem. Read on. 4. Type Ctrl-C (or whatever your UNIX interrupt character is) at the prompt. Do you get "^C..." and a new prompt? If instead, you get a core dump, "rm core" and then rebuild with -DNOCCTRAP added to your CFLAGS. 5. Type Ctrl-Z (or whatever your UNIX suspend character is) to put C-Kermit in the background. Did it work? If nothing happened, then (a) your version of UNIX does not support job control, or (b) your version of C-Kermit was probably built with -DNOJC. If your session became totally frozen, then your are probably running C-Kermit on a UNIX version that supports job control, but under a shell that doesn't. If that's not the case, look in the psuspend() routine in ckutio.c and see if you can figure out what's wrong. If you can't, rebuild with -DNOJC> 6. Try dialing out: SET MODEM <whatever>, SET LINE <whatever>, SET SPEED <whatever>, DIAL <phone-number>. If it doesn't work, keep reading. After dialing, can you REDIAL? 7. If your version was built with TCP/IP network support, try the SET HOST command. 8. Transfer some files in remote mode on incoming asynchronous serial (direct or modem) connections, and on incoming network (telnet, rlogin, terminal server) connections. 9. Establish a serial connection from C-Kermit to another computer (direct or dialed) and transfer some files. If you have network support, do the same with a network connection. 10. If your version was built with fullscreen file transfer display support, check that it works during local-mode file transfer. Also, check C-Kermit's operation afterwards: is the echoing funny? etc etc. 11. If your version was built with script programming language support, TAKE the cketest.ini file to give it a workout. 12. Does C-Kermit interlock correctly with UUCP-family programs (cu, tip, uucp, etc)? If not, read on. REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE 1. Many of C-Kermit's options and features can be deselected at compile time. The greatest savings at the least sacrifice in functionality is to disable the logging of debug information by defining NODEBUG during compilation. See ckccfg.doc for further information. 2. Most UNIX systems have a "strip" command to remove symbol table information from an executable program image. "man strip" for further information. The same effect can be achieved by including "-s" among the link flags when building C-Kermit. 3. SCO, Interactive, and some other UNIX versions have an "mcs" command. "mcs -d wermit" can be used to delete the contents of the ".comment" section from the executable program image. THE FULLSCREEN FILE TRANSFER DISPLAY For fullscreen file transfer display support, add -DCK_CURSES to your makefile entry (if necessary; many entries already have it, generally the ones ending in "c", for example "make sunos41c"). The screen handling is accomplished in UNIX using the curses library. If you are creating a new makefile entry to include the fullscreen display, you must add one of the following to your UNIX makefile entry (whatever works): "LIBS= -lcurses -ltermcap" "LIBS= -lcurses -ltermlib" "LIBS= -lcurses" "LIBS= -ltermlib" to pull in the required libraries. "man curses" for further information, and search through the makefile for "CK_CURSES" to see many examples. In System V, there might be a complication. Apparently System V curses (or at least some implementations of it) reserve the right to alter the buffering on the output file without restoring it afterwards, which can leave Kermit's command processing in a mess when the prompt comes back after a fullscreen file transfer display. If you experience problems such as these, try adding -DCK_NEWTERM to your makefile entry (see comments in screenc() in ckuusx.c for an explanation). In SCO Xenix and SCO UNIX, there are two separate curses libraries, one based on termcap and the other based on terminfo. The default library, usually terminfo, is established when the development system is installed. To manually select terminfo (at compile time): compile -DM_TERMINFO and link -ltinfo and to manually select termcap: compile -DM_TERMCAP and link -ltcap -ltermlib <curses.h> looks at M_TERMINFO and M_TERMCAP to decide which header files to use. /usr/lib/libcurses.a is a link to either libtinfo.a or libtcap.a. The C-Kermit compilation options must agree with the version of the curses library that is actually installed. NOTE: If you are doing an ANSI-C compilation and you get compile time warnings like the following: Warning: function not declared in ckuusx.c: wmove, printw, wclrtoeol, wclear, wrefresh, endwin, etc... it means that your <curses.h> file does not contain prototypes for these functions. The warnings are harmless. C-Kermit maintains a buffer to hold your termcap entry. The size of this buffer is 1024. Reportedly, some termcap entries might be longer than this. To allow for longer termcap entries, add a definition of TRMBUFL to your compilation CFLAGS, for example: -DTRMBUFL=2048 UNIX VERSIONS There are several major varieties of UNIX: Bell Laboratories Seventh Edition, AT&T System V, Berkeley Standard Distribution (BSD), and POSIX. Each has many, many subvarieties and descendents, and there are also hybrids that exhibit symptoms of two or more varieties, plus special quirks of their own. Seventh edition versions of C-Kermit include the compile-time option -DV7 in the CFLAGS string in the makefile entry. Various V7-based implementations are also supported: -DCOHERENT, -DMINIX, etc. AT&T-based versions of UNIX Kermit include the compile-time option -DATTSV (standing for AT&T UNIX System V). This applies to System III and to System V up to and including Release 2. For System V Release 3, the flag -DSVR3 should be used instead (which also implies -DATTSV). This is because the data type of signal() and several other functions was changed between SVR2 and SVR3. For System V Release 4, include -DSVR4 because of changes in uucp lockfile conventions; this also implies -DSVR3 and -DATTSV. For BSD, the flag -BSDxx must be included, where xx is the BSD version number, for example BSD4 (for version 4.2 or later, using only 4.2 features), -DBSD41 (for BSD 4.1 only), -DBSD43 (for 4.3 or later), -DBSD29 (BSD 2.9 for DEC PDP-11s). For POSIX, include the flag -DPOSIX. POSIX defines a whole new set of terminal i/o functions that are not found in traditional AT&T or Berkeley implementations, and also defines the symbol _POSIX_SOURCE, which is used in many system and library header files, mainly to disable non-POSIX features. There is a tendency for UNIX implementations to be neither pure AT&T nor pure BSD nor pure POSIX, but a mixture of two or more of these, with "compatibility features" allowing different varieties of programs to be built on the same computer. In general, Kermit tries not to mix & match but to keep a consistent repertoire throughout. However, there are certain UNIX implementations that only work when you mix and match. For example, the Silicon Graphics Iris workstation IRIX operating system (prior to version 3.3) is an AT&T UNIX but with a BSD file system. The only way you can build Kermit successfully for this configuration is to include -DSVR3 plus the special option -DLONGFN, meaning "pretend I was built with -DBSDxx when it's time to compile directory-related code". See the "iris" makefile entry. STANDARDS In edits 166-167, C-Kermit was heavily modified to try to keep abreast of new standards while still remaining compatible with old versions of C and UNIX. There are two new standards of interest: ANSI C (as described in Kernighan and Ritchie, "The C Programming Language", Second Edition, Prentice Hall, 1988) and POSIX.1 (IEEE Standard 1003.1 and ISO/IEC 9945-1, 1990, "Portable Operating System Interface"). These two standards have nothing to do with each other: you can build C-Kermit with a non-ANSI compiler for a POSIX system, or for a non-POSIX system with with an ANSI compiler. (a) POSIX POSIX.1 defines a repertoire of system functions and header files for use by C language programs. Most notably, the ioctl() function is not allowed in POSIX; all ioctl() functions have been replaced by device-specific functions like tcsetattr(), tcsendbreak(), etc. Computer systems (UNIX, and reportedly also forthcoming versions of VAX/VMS) that claim some degree of POSIX compliance have made some attempt to put their header files in the right places and give them the right names, and to provide system library functions with the right names and calling conventions. Within the header files, POSIX-compliant functions are supposed to be within #ifdef _POSIX_SOURCE..#endif conditionals, and non-POSIX items are not within these conditionals. If C-Kermit is built with the -DPOSIX flag, it attempts to configure itself for a pure POSIX environment. It defines _POSIX_SOURCE, it calls only POSIX-defined functions, and it includes POSIX-defined header files. If Kermit is built with _D_POSIX_SOURCE but not -DPOSIX, C-Kermit must be built with one of the -DBSD or -DATTSV flags (or one that implies them), but still uses only the POSIX features in the system header files. This allows C-Kermit to be built on BSD or AT&T systems that have some degree of POSIX compliance, but still use BSD or AT&T specific features. If Kermit is built with neither _D_POSIX_SOURCE nor -DPOSIX, the functions and header files of the selected version of UNIX (or VMS, etc) are used according to the CFLAGS Kermit was built with. The POSIX standard does not define anything about uucp lockfiles. "make posix" uses NO (repeat, NO) lockfile conventions. If your POSIX-compliant UNIX version uses a lockfile convention such as HDBUUCP (see below), use the "posix" entry, but include the appropriate lockfile option in your KFLAGS on the "make" command line, for example: make posix "KFLAGS=-DHDBUUCP" POSIX.1 also lacks certain other features that Kermit needs. For example: - There is no defined way for an application to do wildcard matching of filenames. Kermit uses the inode in the directory structure, but POSIX does not include this concept. POSIX.2 will include functions for this, named (I think) glob() and fnmatch(), but these functions are not yet in Kermit. - There is no POSIX mechanism for dealing with modem signals, nor to enable RTS/CTS or other hardware flow control. - There is no way to check if characters are waiting in a communications device input buffer, short of trying to read them. - No way to do a millisecond sleep (no nap(), usleep(), select(), etc). - There is no popen(). So at this point, there cannot be one single fully functional POSIX form of C-Kermit unless it also has "extensions". (b) ANSI C The major difference between ANSI C and earlier C compilers is function prototyping. ANSI C allows function arguments to be checked for type agreement, and (when possible) type coercion in the event of a mismatch. For this to work, functions and their arguments must be declared before they are called. The form for function declarations is different in ANSI C and non-ANSI C (ANSI C also accepts the earlier form, but then does not do type checking). As of edit 167, C-Kermit tries to take full advantage of ANSI C features, especially function prototyping. This removes many bugs introduced by differing data types used or returned by the same functions on different computers. ANSI C features are automatically enabled when the symbol __STDC__ is defined. Most ANSI C compilers, such as GNU CC and the new DEC C compiler define this symbol internally. To force use of ANSI C prototypes, include -DCK_ANSIC on the cc command line. To disable the use of ANSI prototypes, include -DNOANSI. UNIX MAKE FAILURES First, be sure the source files are stored on your current disk and directory with the right names (in lowercase). Second, make sure that the makefile itself does not contain any lines with leading spaces: indented lines must all start with horizontal TAB, and no spaces. Then make sure that your UNIX PATH is defined to find the appropriate compiler for your makefile entry. For example, on SunOS systems, "make sunos41" builds C-Kermit for the BSD environment, and assumes that /usr/ucb/cc will be used for compilation and linking. If your PATH has /usr/5bin ahead of /usr/ucb, you can have problems at compile or link time (a commonly reported symptom is the inability to fine "ftime" during linking). Fix such problems by redefining your UNIX PATH, or by specifying the appropriate "cc" in CC= and CC2= statements in your makefile entry. During edits 166-167, considerable effort went into making C-Kermit compilable by ANSI C compilers. This includes prototyping all of C-Kermit's functions, and including the ANSI-defined system header files for system and library functions, as defined in K & R, second edition: <string.h>, <stdlib.h>, <unistd.h> (except on the NeXT this is <libc.h>), and <sys/stdtypes.h>. If you get warnings about any of these header files not being found, or about argument mismatches involving pid_t, uid_t, or gid_t, look in ckcdeb.h and make amendments. C-Kermit assumes it is being compiled by an ANSI-compliant C compiler if __STDC__ is defined, normally defined by the compiler itself. You can force ANSI compilation without defining __STDC__ (which some compilers won't let you define) by including -DCK_ANSIC on the cc command line. On the other hand, if your compiler defines __STDC__ but still complains about the syntax of Kermit's function prototypes, you can disable the ANSI-style function prototyping by including -DNOANSI on the command line. For SCO UNIX, ODT, and XENIX compilations, be sure to pick the most appropriate makefile entry, and be sure you have installed an SCO development system that is keyed to your exact SCO operating system release, down to the minor version (like 2.3.1). There seems to be a lot of controversy about whether to use the SCO Shared Libraries (lc_s), especially when building C-Kermit with curses or network support. One user claims that an executable built under one version of SCO UNIX (say 3.2.2) will not run correctly on another version (say 3.2.4). More on SCO: In version 3.2.2 the order in which libc and libx are searched is important for the directory-reading routines (opendir). When using <ndir.h>, libx must be searched before libc (-lx -lc). In version 3.2.4, <dirent.h> and libc should be used. One user recommends the following for 3.2.2: -lx -lx -lsocket (net version) and for 3.2.4: -lc -lx -lc -lx -lsocket (net version) If you have problems at link or run time with a SCO 3.2.x version of C-Kermit, try juggling these items in the makefile entry. If your compiler uses something other than int for the pid (process id) data type, put -DPID_T=pid_t or whatever in your CFLAGS. If you get complaints about unknown data types uid_t and gid_t, put -DUID_T=xxx -DGID_T=yyy in your CFLAGS, where xxx and yyy are the appropriate types. If you get complaints that getpwuid() is being called with an improper type, put -DPWID_T=xx in your CFLAGS. If the compiler complains about the declaration of getpwnam() during an ANSI C compilation, remove the declaration from ckufio.c or change the argument in the prototype from (char *) to (const char *). If you get compile-time warnings that t_brkc or t_eofc (tchars structure members, used in BSD-based versions) are undefined, or structure-member- related warnings that might be traced to this fact, add -DNOBRKC to CFLAGS. If you get a linker message to the effect that _setreuid or _setregid is not defined, add -DNOSETREU to CFLAGS, or add -DCKTYP_H=<blah> to CFLAGS to make C-Kermit read the right <types.h>-kind-of-file to pick up these definitions. If you get a message that _popen is undefined, add -DNOPOPEN to CFLAGS. If you get a complaint at compile time about an illegal pointer-integer combination in ckufio.c involving popen(), or at link time that _popen is an undefined symbol, add the declaration "FILE *popen();" to the function zxcmd() in ckufio.c (this declaration is supposed to be in <stdio.h>). If making this change does not help, then apparently your UNIX does not have the popen() function, so you should add -DNOPOPEN to your make entry, in which case certain functions involving "file" i/o to the standard input and output of subprocesses will not be available. If your linker complains that _getcwd is undefined, you can add a getcwd() function to ckufio.c, or add it to your libc.a library using ar: #include <stdio.h> char * getcwd(buf,size) char *buf; int size; { #ifndef NOPOPEN #ifdef DCLPOPEN FILE *popen(); #endif FILE *pfp; if (!buf) return(NULL); if (!(pfp = popen("pwd","r"))) return(NULL); fgets(buf,size-2,pfp); pclose(pfp); buf[strlen(buf)-1] = '\0'; return((char *)buf); #else buf[0] = '\0'; return(NULL); #endif /* NOPOPEN */ } #ifdef NOPOPEN FILE *popen(s,t) char *s,*t; { return(NULL); } #endif /* NOPOPEN */ If you get complaints about NPROC having an invalid value, add a valid definition for it (depends on your system), as in the cray entry. If you get some symbol that's multiply defined, it probably means that a variable name used by Kermit is also used in one of your system libraries that Kermit is linked with. For example, under PC/IX some library has a variable or function called "data", and the variable "data" is also used extensively by Kermit. Rather than edit the Kermit source files, just put a -D in the make entry CFLAGS to change the Kermit symbol at compile time. In this example, it might be -Ddata=datax. Some symbol is defined in your system's header files, but it produces conflicts with, or undesired results from, Kermit. Try undefining the symbol in the makefile entry's CFLAGS, for example -UFIONREAD. Some well-known symbol is missing from your system header files. Try defining in the makefile entry's CFLAGS, for example -DFREAD=1. You get many warnings about pointer mismatches. This probably means that Kermit is assuming an int type for signal() when it should be void, or vice-versa. Try adding -DSIG_I (for integer signal()) or -DSIG_V (for void) to CFLAGS. Or just include KFLAGS=-DSIG_V (or whatever) in your "make" command, for example: make bsd KFLAGS=-DSIG_V You get many messages about variables that are declared and/or set but never used. It is difficult to avoid these because of all the conditional compilation in the program. Ignore these messages. Some of C-Kermit's modules are so large, or contain so many character string constants, or are so offensive in some other way, that some C compilers give up and refuse to compile them. This is usually because the -O (optimize) option is included in the make entry. If this happens to you, you can (a) remove the -O option from the make entry, which will turn off the optimizer for ALL modules; (b) compile the offending module(s) by hand, including all the switches from make entry except for -O, and then give the appropriate "make" command again; or (c) increase the value of the -Olimit option, if your compiler supports this option. As an extreme example, some compilers (e.g. gcc on the DG Aviion) have been known to dump core when trying to compile ckwart.c with optimization. So just do this one "by hand": cc -o wart ckwart.c and then give the "make" command again. Speaking of wart, it is unavoidable that some picky compilers might generate "statement unreachable" messages when compiling ckcpro.c. Unreachable statements can be generated by the wart program, which generates ckcpro.c automatically from ckcpro.w, which translates lex-like state/input constructions into a big switch/case construction. Some function in Kermit wreaks havoc when it is called. Change all invocations of the function into a macro that evaluates to the appropriate return code that would have been returned by the function had it been called and failed, for example: -Dzkself()=0. Obviously not a good idea if the function is really needed. If you have just installed SunOS 4.1.2 or 4.1.3, you might find that C-Kermit (and any other C program) fails to link because of unresolved references from within libc. This is because of a mistake in Sun's /usr/lib/shlib.etc files for building the new libc. Change the libc Makefile so that the "ld" lines have "-ldl" at the end. Change the README file to say "mv xccs.multibyte. xccs.multibyte.o" and follow that instruction. UNIX FILE SYSTEM PECULIARITIES Normally, including a BSD, System-V, POSIX, or DIRENT flag in the make entry selects the right file system code. But more recent versions of UNIX are inconsistent in this regard, and building in the normal way either gives compiler or linker errors, or results in problems at runtime, typically failure to properly expand wildcard file specifications when you do something like "send *.*", or failure to recognize long filenames, as in "send filewithaverylongname". File creation dates: C-Kermit attempts to set the creation date/time of an incoming file according to the date/time given in the file's attribute packet, if any. If you find that the dates are set incorrectly, you might need to build Kermit with the -DSYSUTIMEH flag, to tell it to include <sys/utime.h>. C-Kermit is supposed to know about all the various styles of UNIX file systems, but it has to be told which one to use when you build it, usually in the makefile entry CFLAGS as shown below, but you might also have to add something like -I/usr/include/bsd to CFLAGS, or something like -lbsd to LIBS. C-Kermit gives you the following CFLAGS switches to adapt to your file system's peculiarities: -DDIRENT - #include <dirent.h> -DSDIRENT - #include <sys/dirent.h> -DNDIR - #include <ndir.h> -DXNDIR - #include <sys/ndir.h> -DRTU - #include "/usr/lib/ndir.h", only if NDIR and XNDIR not defined. -DSYSUTIMH - #include <sys/utime.h> for setting file creation dates. (Note, RTU should only be used for Masscomp RTU systems, because it also selects certain other RTU-specific features.) If none of these is defined, then <sys/dir.h> is used, which is (currently) the most common case. IMPORTANT: If your system has the file /usr/include/dirent.h then be sure to add -DDIRENT to your makefile entry's CFLAGS. "dirent" should be used in preference to any of the others, because it supports all the features of your file system, and the others probably don't. Having selected the appropriate directory header file, you might also need to tell Kermit how to declare the routines and variables it needs to read the directory. This happens most commonly on AT&T System-V based UNIXes, particularly System V R3 and earlier, that provide long file and directory names (longer than 14 characters). Examples include certain releases of HP-UX, DIAB DNIX, older versions of Silicon Graphics IRIX, and perhaps also MIPS. In this case, try adding -DLONGFN to your makefile entry. For further details, see the discussion under edit 5A(149) in the program update history, ckuker.upd. Another problem child is <sys/file.h>. Most UNIX C-Kermit versions need to #include this file from within ckutio.c and ckufio.c, but some not only do not need to include it, but MUST not include it because (a) it doesn't exist, or (b) it has already been included by some other header file and it doesn't protect itself against multiple inclusion, or (c) some other reason that prevents successful compilation. If you have compilation problems that seem to stem from including this file, then add the following switch to CFLAGS in your makefile entry: -DNOFILEH There are a few odd cases where <sys/file.h> must be included in one of the cku[ft]io.c files, but not the other. In that case, add the aforementioned switch, but go into the file that needs <sys/file.h> and add something like this: #ifdef XXX /* (where XXX is a symbol unique to your system) */ #undef NOFILEH #endif /* XXX */ before the section that includes <sys/file.h>. Kermit's SEND command expands wildcard characters "?" and "*" itself. Before version 5A, commands like "send *" would send all regular (non-directory) files, including "hidden files" (whose names start with "."). In version 5A, the default behavior is to match like the Bourne shell or the ls command, and not include files whose names start with dot. Such files can still be sent if the dot is included explicitly in the SEND command: "send .oofa, send .*". To change back to the old way and let leading wildcard characters match dot files, include the following in your CFLAGS: -DMATCHDOT If you get compile-time complaints about data type mismatches for process-ID related functions like getpid(), add -DPID_T=pid_t. If you get compile-time complaints about data type mismatches for user ID related functions like getuid(), add -DUID_T=uid_t. If you get compile-time complaints about data type mismatches for user-ID related functions like getgid(), add -DGID_T=gid_t. If you get compile-time complaints about data type mismatches for getpwuid(), add -DPWID_T=uid_t (or whatever it should be). HARDWARE FLOW CONTROL Hardware flow control is, in general, a problematic concept in many popular UNIX implementations. Often it is lacking altogether, and when available, the application program interface (API) to it is inconsistent from system to system. Here are some examples: 1. POSIX does not support hardware flow control. 2. RTS/CTS flow control support MIGHT be available for System V R3 and later if /usr/include/termiox.h exists (its successful operation also depends on the device driver, and the device itself, not to mention the cable, etc, actually supporting it). If your SVR3-or-later UNIX system does have this file, add: -DTERMIOX to your CFLAGS. If the file is in /usr/include/sys instead, add: -DSTERMIOX Note that the presence of this file does not guarantee that RTS/CTS will actually work -- that depends on the device-driver implementation (reportedly, many UNIX versions treat hardware-flow-control related ioctl's as no-ops). 3. Search (grep) through /usr/include/*.h and /usr/include/sys/*.h for RTS or CTS and see what turns up. For example, in SunOS 4.x we find "CRTSCTS". Figuring out how to use it is another question entirely! In IBM AIX RS/6000, we have to "add" a new "line discipline" (and you won't find uppercase RTS or CTS symbols in the header files). 4. NeXTSTEP supports hardware flow control, but does not furnish an API to control it, and thus NeXTSTEP Kermit has no command to select it -- instead, a special device name must be used. 5. RTS/CTS is available in Linux, but you have to place a line like: stty crtscts < /dev/modem in your /etc/rc.local file (where /dev/modem is the device name of any serial device that you want to have RTS/CTS flow control enabled). See the routine tthflow() in ckutio.c for details. If you find that your system offers hardware flow control selection under program control, you can add this capability to C-Kermit as follows: 1. See if it agrees with one of the methods already used in tthflow(). If not, add new code, appropriately #ifdef'd. 2. Add -DCK_RTSCTS to the compiler CFLAGS in your makefile entry or define this symbol within the appropriate #ifdef's in ckcdeb.h. To illustrate the difficulties with RTS/CTS, here is a tale from Jamie Watson <jw@adasoft.ch>, who added the RTS/CTS code for the RS/6000, about his attempts to do the same for DEC ULTRIX: "The number and type of hardware signals available to/from a serial port vary between different machines and different types of serial interfaces on each machine. This means that, for example, there are virtually no hardware signals in or out available on the DECsystem 3000/3100 series; on the DECsystem 5000/2xx series all modem signals in/out are present on both built-in serial ports; on the DECsystem 5100 some ports have all signals and some only have some; and so on... It looks to me as if this pretty well rules out any attempt to use hardware flow control on these platforms, even if we could figure out how to do it. The confusion on the user level about whether or not it should work for any given platform or port would be tremendous. And then it isn't clear how to use the hardware signals even in the cases where the device supports them." OTHER SYSTEM-DEPENDENT FEATURES There is no standard for millisecond sleeps, but at least three different functions have appeared in various UNIX versions that can be used for this purpose: nap() (mostly in System V), usleep() (found at least in SunOS and NeXT OS), and select() (found in 4.2BSD and later). If you have any of these available, pick one: -DNAP: Include this in CFLAGS if your system has the nap() function. -DSELECT: Include this in CFLAGS if your system has the select() function. -USLEEP: Include this in CFLAGS if your system has the usleep() function. NOTE: The nap() function is assumed to be a function that puts the process to sleep for the given number of milliseconds. If your system's nap() function does something else or uses some other units of time (like the NCR Tower 32, which uses clock-ticks), do not include -DNAP. Reportedly, all versions of System V R4 for Intel-based computers, and possibly also SVR3.2, include nap() as a kernel call, but it's not in the library. To include code to use it via syscall(3112,x), without having to include Xenix compatibility features, include the following compile-time option: -DNAPHACK Many AT&T UNIX versions have no way to check if input is waiting on a tty device. This is a very important feature for Kermit. Without it, sliding windows might not work very well (or at all), and you also have to type your escape character to get Kermit's attention in order to interrupt a local-mode file transfer. However, certain System-V variations, mostly those from SCO, include a rdchk() function. If your version of UNIX had rdchk(), include: -DRDCHK: Include this in CFLAGS if your system has the rdchk() function. Otherwise, if your version of UNIX has the poll() function (and the /usr/include/poll.h file), include: -DCK_POLL Systems with <termios.h> might have the symbol IEXTEN defined. This is used to turn ^V/^O processing on and off. It should be turned off during Kermit operation, so if ckutio.c finds this symbol, it uses it. This is necessary, at least, on BSDI. On some systems, however, IEXTEN is either misdefined or misimplemented. The symptom is that CR, when typed to the command processor, is echoed as LF, rather than CRLF. This happens (at least) on Convex/OS 9.1. The solution is to add the following symbol to the makefile entry's CFLACS: -DNOIEXTEN In edits 177 and earlier, workstation users noticed a "slow screen writing" phenomenon during interactive command parsing. This was traced to a setbuf() call in ckutio.c that made console (stdout) writes unbuffered. This setbuf() call has been there forever, and probably can't be removed without some risk. Kermit's operation was tested on the NeXT in edit 178 with the setbuf() call removed, and the slow-writing symptom was cured, and everything else (command parsing, proper wakeup on ?, ESC, Ctrl-U, and other editing characters, terminal emulation, remote-mode and local-mode file transfer, etc) seemed to work as well as or better than before. To remove the setbuf() call for your version of Kermit, add: -DNOSETBUF Later reports indicate that adding -DNOSETBUF has other beneficial effects, like cutting down on swapping when Kermit is run on workstations with small memories. But BEWARE: on certain small UNIX systems, notably the AT&T 6300 and 3B1 (the very same ones that benefit from NOSETBUF), NOSETBUF seems to conflict with CK_CURSES. The program builds and runs OK, but after once using the curses display, echoing is messed up. In this case, we use a System-V specific variation in the curses code, using newterm() to prevent System V from altering the buffering. See makefile entries for AT&T 6300 and 3B1. The UNIX version of C-Kermit includes code to switch to file descriptor zero (stdin) for remote-mode file transfer. This code is necessary to prevent Kermit from giving the impression that it is "idle" during file transfers, which, at some sites, can result in the job being logged out by idle-job watchers. However, this feature can interfere with certain setups; for example, there is a package which substitutes a pty/tty pair for /dev/tty and sets file descriptor 0 to be read-only, preventing Kermit from sending packets. To remove this feature and allow Kermit to work in such environments, add the compile-time option: -DNOFDZERO Some versions of UNIX render a tty device unusable after a hangup operation. Examples include IBM AIX on the RT PC and RS/6000. A typical symptom of this phenomenon is that the DIAL command doesn't work, but CONNECTing to the device and dialing manually do work. A further test is to SET DIAL HANGUP OFF, which should make dialing work once by skipping the pre-dial hangup. However, after the connection is broken, it can't be used any more: subsequent attempts to DIAL the same device won't work. The cure is usually to close and reopen the device as part of the hangup operation. To do this, include the following compile-time option: -DCLSOPN Similarly, there is a section of code in ttopen(), which does another close(open()) to force the O_NDELAY mode change. On some systems, the close(open()) is required to make the mode change take effect, and apparently on most others it does no harm. But reportedly on at least one System V R4 implementation, and on SCO Xenix 3.2, the close(open()) operation hangs if the device lacks carrier, EVEN THOUGH the CLOCAL characteristic has just been set to avoid this very problem. If this happens to you, add this to your CFLAGS: -DNOCOTFMC or, equivalently, in your KFLAGS on the make command line. It stands for NO Close(Open()) To Force Mode Change. C-Kermit renames files when you give a RENAME command and also according to the current SET FILE COLLISION option when receiving files. The normal UNIX way to rename a file is via two system calls: link() and unlink(). But this leaves open a window of vulnerability. Some UNIX systems also offer an atomic rename(oldname,newname) function. If your version of UNIX has this function, add the following to your CFLAGS: -DRENAME C-Kermit predefines the RENAME for several UNIX versions in ckcdeb.h (SVR4, SUNOS41, BSD44, AIXRS, etc). You can tell if rename() is being used if the SHOW FEATURES command includes RENAME in the compiler options list. If the predefined RENAME symbol causes trouble, then add NORENAME to your CFLAGS. Finally, here's a switch you should NEVER set: -DCOMMENT It's used for commenting out blocks of code. If for some reason you find that your compiler has COMMENT defined, then add -UCOMMENT to CFLAGS! TERMINAL INTERRUPTION When C-Kermit enters interactive command mode, it sets a Control-C (terminal keyboard interrupt = SIGINT) trap to allow it to return to the command prompt whenever the user types Control-C (or whatever is assigned to be the interrupt character). This is implemented using setjmp() and longjmp(). On some systems, depending on the machine architecture and C compiler, you might get "Memory fault (coredump)" or "longjmp botch" instead of the desired effect. In that case, add -DNOCCTRAP to your CFLAGS and rebuild the program. Job control -- the ability to "suspend" C-Kermit on a UNIX system by typing the "susp" character (normally Ctrl-Z) and then resume execution later (with the "fg" command) -- is a tricky business. C-Kermit must trap suspend signals so it can put the terminal back into normal mode when you suspend it (Kermit puts the terminal into various strange modes during interactive command parsing, CONNECT, and file transfer). Supporting code is compiled into C-Kermit automatically if <signal.h> includes a definition for the SIGTSTP signal. HOWEVER... some systems define this signal without supporting job control correctly. You can build Kermit to ignore SIGTSTP signals by including the -DNOJC option in CFLAGS. (You can also do this at runtime by giving the command SET SUSPEND OFF.) System V R3 and earlier systems normally do not support job control. If you have an SVR3 system that does, include the following option in your CFLAGS: -DSVR3JC DIALING OUT AND COORDINATING WITH UUCP Make sure your dialout line is correctly configured for dialing out (as opposed to login). The method for doing this is different for each kind of UNIX system. Consult your system documentation for configuring lines for dialing out (for example, SUN SparcStation IPC users should read the section "Setting up Modem Software" in the Desktop SPARC Sun System & Network Manager's Guide). Unlike other operating systems, UNIX allows multiple processes to access the same tty device at the same time, even though there is no earthly reason why two processes would want to do this. When they do, process A will read some of the incoming characters, and process B will read the others. Neither process will see them all. As you can imagine, this can cause enormous difficulties for any communication program. Rather than change UNIX to make exclusive access to tty devices be the default, UNIX vendors hit upon the idea of a "lock file". Any process that wants to open a tty device should first check and see if a file of a certain name exists, and if so, not to open the device. If the file does not exist, the process creates the file and then opens the device. When the process closes the device, it destroys the lockfile. This procedure was originated for use with UNIX's UUCP, CU, and TIP programs, and so these lockfiles are commonly called "UUCP lockfiles" (UUCP = UNIX-to-UNIX Copy Program). As you can imagine, this method is riddled with pitfalls: - If a process does not observe the lockfile convention (or the SAME lockfile convention), then it can interfere with other "polite" processes. - If a process crashes while it has the device open, the lockfile is left behind, preventing further processes from using the device. - Various versions of UNIX use different names for the lockfiles, put them in different directories, and specify their contents differently. - On a given system, the lockfile conventions may change from one UNIX release to the next (for example, SUNOS 4.0 to 4.1). - The same tty device might have more than one name, and many lockfile conventions don't allow for this. In order to fit in with UUCP and other UNIX-based communication software, C-Kermit must have the same idea as your system's uucp, cu, and tip programs about what the UUCP lock directory is called, what the lockfile itself is called, and what its contents should be. In most cases, Kermit tries to figure this out automatically (see ckutio.c). The following CFLAGS options can be used to override C-Kermit's normal assumptions: -DLCKDIR: Tells Kermit that the UUCP lock directory is /usr/spool/uucp/LCK. -DACUCNTRL: Tells Kermit to use the BSD 4.3 acucntrl() program to turn off getty (login) on the line before using it, and restore getty when done. -DHDBUUCP: Include this if your system uses Honey DanBer UUCP. -DLOCK_DIR=\\\"/xxx/yyy\\\": Gives the lock directory name explicitly. The triple quoting is necessary. For example: "CFLAGS= -DBSD4 -DLOCK_DIR=\\\"/usr/local/locks\\\" -DNODEBUG" -DLFDEVNO The lockfile name uses the tty device inode and major and minor numbers: LK.dev.maj.min, as in Sys V R4, e.g. LK.035.044.008. Honey DanBer (HDB) UUCP, which is becoming increasingly popular, has two characteristics: a. Lockfiles are kept in /usr/spool/locks/. b. A lockfile contains the process id (pid) in ASCII, rather than as an int. All non-HDB selections assume the lockfile contains the pid in int form (or, more precisely, in PID_T form, where PID_T is either int or pid_t, depending on your system's C library and header files). Even if you build the program with the right lockfile option, you can still have problems when you try to open the device. Here are the error messages you can get from SET LINE, and what they mean: a. "Timed out, no carrier." This one is not related to lockfiles. It means that you have SET CARRIER ON xx, where xx is the number of seconds to wait for carrier, and carrier did not appear within xx seconds. Solution: SET CARRIER AUTO or OFF. b. "Sorry, access to lock denied." Kermit has been configured to use lockfiles, but (a) the lockfile directory is write-protected against you, or (b) it does not exist. The "access to lock denied" message will tell you the reason. If the lockfile does not exist, check to make sure Kermit is using the right name. Certain recent releases of UNIX have changed the location of the lockfile from /usr/spool/whatever to /var/spool/whatever. In this case, ask the system manager install a symbolic link from the old name to the new name. Other solutions: (see below) c. "Sorry, access to tty device denied." The tty device that you specified in your SET LINE command is read/write protected against you. Solution: (see below) d. "Sorry, device is in use." The tty device you have specified is currently being used by another user. A prefatory message gives you an "ls -l" listing of the lockfile, which should show the username of the person who created it, plus a message "pid = nnn" to show you the process id of the user's program. Solutions: try another device, wait until the other user is finished, ask the other user to hurry up, or ask the system manager for help. e. "Sorry, can't open connection: <reason>". The device cannot be opened for some other reason, which is listed. f. "sh: /usr/lib/uucp/acucntrl: not found". This means your Kermit program was built with the -DACUCNTRL switch, but your computer system does not have the BSD 4.3 acucntrl program. Solution: install the acucntrl program if you have it, or rebuild Kermit without the -DACUCNTRL switch. There are two solutions for problems (b) and (c), both of which involve intervention by the manager (superuser) of your UNIX system: a. Have the superuser change the permission of the lockfile directory and to the tty devices so that everyone on the system has read/write permission. su% chmod 777 /usr/spool/locks (or whatever the path is) su% chmod 666 /dev/ttyXX The risk here is that people can write lots of junk into the lockfile directory, delete other people's files in the lockfile directory, and intercept other people's data as it goes in and out of the tty device. The major danger here would be intercepting a privileged password. Of course, any user could write a short, ordinary, unprivileged program to do exactly the same thing! b. Have the superuser change Kermit to run setuid or setgid to the owner of the lockfile directory (and the tty devices if necessary), typically uucp (see next section). su% chown uucp kermit su% chmod u+s kermit (setuid) - or - chmod g+s kermit (setgid) and then make sure the lockfile directory, and the tty devices, have owner (setuid) and/or group (setgid) write permission. For example: su% chmod o+rwx /usr/spool/uucp su% chown uucp /dev/ttyXX ; chmod 600 /dev/ttyXX On the whole, the setuid option should be avoided whenever possible, because any loophole in this enormously complicated program could be exploited to grant the user the privileges of the user to whom the program is setuid'd or setgid'd to. For the lockfile mechanism to achieve its desired purpose -- prevention of access to the same tty device by more than one process at a time -- ALL programs on a given computer that open, read or write, and close tty devices must use the SAME lockfile conventions. Unfortunately, this is often not the case. Here is a typical example of how this can go wrong: In SunOS 4.0 and earler, the lockfile directory was /usr/spool/uucp; in 4.1 it was changed to /var/spool/locks. Therefore, any programs that were not modified to account for this change, recompiled, and reinstalled, will not be using the same lockfiles as uucp, tip, etc, and so the entire purpose of the lockfile is defeated. What if your UNIX system does not have UUCP installed? For example, you have a UNIX workstation, and you do not use uucp, cu, or tip, or UUCP was not even supplied with your version of UNIX. In this case, you have two choices: a. If there may be more than one person running Kermit at the same time, competing for the same tty device, then create a special lockfile directory just for Kermit, for example, /usr/spool/kermit, and make sure you have read/write access to it. Then add the following to your makefile entry CFLAGS, as shown earlier: -DLOCK_DIR=\\\"/usr/spool/kermit\\\" b. If you are the only user on your workstation, and no other processes will ever be competing with Kermit for the dialout tty device, then add -DNOUUCP to your makefile entry's CFLAGS and rebuild Kermit. RUNNING UNIX C-KERMIT SETUID OR SETGID Even if you don't intend to run C-Kermit setuid, somebody else might come along and chown and chmod it after it has been built. You should be sure that it is built correctly to run setuid on your system. For AT&T UNIX versions, you don't have to do anything special. For BSD-based UNIX versions, 4.2 and later, you normally need not add anything special to the makefile. The program assumes that the setreuid() and setregid() functions are available, without which we cannot switch back & forth between real & effective uids. If "make" complains that _setreuid or _setregid is/are not defined, add -DNOSETREU to CFLAGS. In this case it is very likely (but not certain) that you cannot protect ttys and lockfiles against people and have them run Kermit setuid. If make does not complain about this, you should find out whether your BSD version (4.3 or later, or other systems like SunOS 4.x that claim to include BSD 4.3 compatibility) includes the saved-setuid feature (see long notes under edit 146 in ckuker.upd). If it does, then add -DSAVEDUID to CFLAGS. IMPORTANT NOTE: Most UNIX system documentation will not give you the required information. To determine whether your UNIX system supplies the the saved-original-effective-user/group-id feature, use the ckuuid.c program. Read and follow the instructions in the comments at the beginning. If you have a version of UNIX that is not BSD-based, but which supplies the setreuid() and setregid() functions, and these are the only way to switch between real and effective uid, add -DSETREUID to your makefile entry. WARNING: There are two calls to access() in ckufio.c, by which Kermit checks to see if it can create an output file. These calls will not work correctly when (a) you have installed C-Kermit setuid or setgid on a BSD-based UNIX system; (b) the saved-original-effective-uid/gid feature is not present; and (c) the access() function always checks what it believes to be the real ID rather than the effective ID. This is the case, for example, in Olivetti X/OS and in NeXTSTEP. In such cases, you can force correct operation of access() calls by including defining the symbol SW_ACC_ID at compile time in the CFLAGS. If you have a version of UNIX that does not allow a process to switch back and forth between its effective and real user and group ids multiple times, you probably should not attempt to run Kermit setuid, because once having given up its effective uid or gid (which it must do in order to transfer files, fork a shell, etc) it can never get it back, and so it can not use the original effective uid or gid to create or delete uucp lockfiles. In this case, you'll either have to set the permissions on your lockfile directory to make them publicly read/writable, or dispense with locking altogether. CONFIGURING UNIX WORKSTATIONS On desktop workstations that are used by only the user at the console keyboard, C-Kermit is always used in local mode. But as delivered, C-Kermit runs in remote mode by default. To put it in local mode at startup, you can put a SET LINE command in your .kermrc. You can also build C-Kermit to start up in local mode by default. To do this, include the following in the CFLAGS in your makefile entry: -DDFTTY=\\\"/dev/ttyxx\\\" where ttyxx is the name of the device you will be using for communications. Presently there is no way of setting the default modem type at compile time, so use this option only for direct lines. C-Kermit does not work well on certain workstations if it is not run from within a terminal window. For example, you cannot start C-Kermit on a NeXT by launching it directly from NeXTstep. Similarly for SUN workstations in the Open Windows environment. Run Kermit in a terminal window. BIZARRE BEHAVIOR AT RUNTIME See the beware file, ckuker.bwr, for hints about runtime misbehavior. This section lists some runtime problems that can be cured by rebuilding C-Kermit. The program starts, but there is no prompt, and certain operations don't work (you see error messages like "Kermit command error in background execution"). This is because Kermit thinks it is running in the background. See conbgt() in ckutio.c. Try rebuilding Kermit with: -DPID_T=pid_t added to your CFLAGS. If that doesn't help, find out the actual data type for pids (look in types.h or similar file) and use it in place of "pid_t", for example: -DPID_T=short Unexplainable and inappropriate error messages ("Sockets not supported on this device", etc) have been traced in at least one case to a lack of agreement between the system header files and the actual kernel. This happened because the GNU C compiler (gcc) was being used. gcc wants to have ANSI-C-compliant header files, and so part of the installation procedure for gcc is to run a shell script called "fixincludes", which translates the system's header files into a separate set of headers that gcc likes. So far so good. Later, a new version of the operating system is installed and nobody remembers to run fixincludes again. From that point, any program compiled with gcc that makes use of header files (particularly ioctl.h) is very likely to misbehave. Solution: run fixincludes again, or use your system's regular C compiler, libraries, and header files instead of gcc. CRASHES AND CORE DUMPS Total failure of the Kermit program can occur because of bad memory references, bad system calls, or problems with dynamic memory allocation. First, try to reproduce the problem with debugging turned on: run Kermit with the -d command-line option (for example, "wermit -d") and then examine the resulting debug.log file. The last entry should be in the vicinity of the crash. In VAX/VMS, a crash automatically produces a "stack dump" which shows the routine where the crash occurs. In UNIX, you can get a stack dump with "adb" -- just type "adb wermit core" and then give the command "$c", then Ctrl-D to quit. In edit 186, one implementation, UNISYS 5000/95 built with "make sys5r3", has been reported to run out of memory very quickly (e.g. while executing a short initialization file that contains a SET DIAL DIRECTORY command). Debug logs show that malloc calls are failing, reason unknown. For this and any other implementation that gives error messages about "malloc failure" or "memory allocation failure", rebuild the program *without* the -DDYNAMIC CFLAGS definition, for example: make sys5r3 KFLAGS=-UDYNAMIC As of edit 169, C-Kermit includes a malloc() debugging package which you may link with the Kermit program to catch runtime malloc errors. See the makefile entries for sunos41md and nextmd for examples of how to select malloc debugging. Once you have linked Kermit with the malloc debugger, it will halt with an informative message if a malloc-related error occurs and, if possible, dump core. For this reason, malloc-debugging versions of Kermit should be built without the "-s" link option (which removes symbols, preventing analysis of the core dump). You have several ways to track down the malloc error: reproduce the problem with "log debug" and then look at the code around the last debug.log entry. Or run the program under gdb. Or analyze the core dump with adb. (End of CKUINS.DOC)